ZippDrive — PROD Infrastructure Proposal

The current problem

PROD runs on a single 4-core DigitalOcean droplet today. We logged in and measured it directly rather than estimating — it's already at capacity, and the cause is specific enough to fix.

4.31

Load average (5 min), on 4 vCPUs — effectively full

31 GB

PostgreSQL data, growing

19 GB

MinIO object storage

74%

Disk used (113 of 154 GB)

What's actually competing for CPU

Measured live, mid-morning — a routine moment, not a spike

All three share the same 4 cores. The backup job isn't idle overhead — it's a direct competitor.

postgres 58.3%

API (dotnet) 50.0%

pg_dump 41.7%

everything else ~13%

The observability stack (Grafana, Prometheus, Tempo, Seq, and three exporters) — the part that looks like it should be the overhead — is actually the cheapest thing running, at roughly 13% CPU combined. The real story is PostgreSQL, the API, and the scheduled backup dump all fighting for the same four cores, and that backup dump repeats six times a day.

Proposed architecture

Split the database onto its own server. Nothing else needs separating — Mongo, MinIO, OSRM, and the full observability stack are all cheap enough to share the application server.

flowchart TB
    U["Riders & drivers<br/>mobile / web"] -->|HTTPS| CF{{"Cloudflare<br/>DNS · CDN · WAF (optional)"}}
    CF --> TR["Traefik<br/>TLS termination"]

    subgraph APP["Application VPS — KVM 4 / KVM 8"]
        TR --> API["ZippDrive API<br/>.NET · zero-downtime rolling deploy"]
        API --> MONGO[("MongoDB")]
        API --> MINIO[("MinIO<br/>object storage")]
        API --> OSRM["OSRM<br/>routing engine"]
        API -. "metrics · traces · logs" .-> OBS["Prometheus · Grafana<br/>Tempo · Seq"]
    end

    subgraph DBTIER["Database VPS — KVM 4"]
        PG[("PostgreSQL")]
        REDIS[("Redis")]
    end

    API -->|SQL| PG
    API -->|cache / session| REDIS

    PG -. "pg_dump, every 4h" .-> SPACES[("DigitalOcean Spaces<br/>existing bucket — reused as-is")]
    MONGO -. "mongodump, daily" .-> SPACES
    MINIO -. "mc mirror, daily" .-> SPACES

Solid lines are live request traffic. Dashed lines are backup and telemetry flows. Cloudflare is a drop-in addition in front of Traefik — see section 05.

Database tier

PostgreSQL + Redis

Removes API + backup contention
Gains full 4 cores to itself
Headroom for 31 GB dataset to grow

Application tier

API + Mongo + MinIO + OSRM + observability

API .NET, Swarm rolling deploy
Storage MongoDB, MinIO
Routing OSRM
Telemetry Prometheus, Grafana, Tempo, Seq

Backup strategy

No backup migration is required. The existing pipeline uploads to DigitalOcean Spaces over a plain HTTPS S3 API — it was never actually tied to the droplet being hosted at DigitalOcean, so the same bucket keeps working unchanged from Hostinger.

PostgreSQL pg_dump → gzip → stream

Selected tables + full schema dumped every 4 hours, streamed directly to Spaces without a large local temp file. Last 4 backups retained, older ones pruned automatically.
MongoDB mongodump → gzip archive

Full database archive once daily, uploaded to Spaces. Same 4-backup retention policy.
MinIO mc mirror --overwrite

Incremental mirror to Spaces once daily — only changed objects transfer after the first sync, so this stays lightweight even as the bucket grows.
Destination DigitalOcean Spaces

Same bucket as today (zipp-drive, Singapore region). Reached over its public S3 endpoint — no dependency on where the servers themselves are hosted.

Recommended follow-up: once the database is on its own server, the pg_dump job is no longer competing with the API — but it's still running against the live PostgreSQL primary. The next step worth planning is a small streaming replica dedicated to backups, so the 4-hourly dump reads from a standby instead of the server handling real traffic. Not required for launch; worth scheduling shortly after.

Server plans & cost

Hostinger's current KVM lineup, matched against what each tier actually needs to run.

Hostinger VPS plan comparison
Role	Plan	vCPU	RAM	Disk	Intro / mo	Renews / mo
Database (PostgreSQL + Redis)	KVM 4	4	16 GB	200 GB	₹1,099	₹2,399
Application (API + Mongo + MinIO + OSRM + observability)	KVM 4	4	16 GB	200 GB	₹1,099	₹2,399
Application — with growth headroom	KVM 8	8	32 GB	400 GB	₹2,199	₹4,399

₹2,198

Minimum viable total — KVM 4 + KVM 4, intro price

₹3,298

With headroom — KVM 4 + KVM 8, intro price

Both options already beat today's single-droplet cost while roughly doubling total available compute (4 shared cores today → 8 dedicated cores split across two purpose-built servers). Prices shown are Hostinger's current promotional rate — budget against the renewal price for the ongoing run-rate.

Cloudflare — optional, recommended

Free tier is enough to start. It sits in front of Traefik, not in place of it.

Included on Free	Notes
DNS + Universal SSL	Replaces nothing already in place, adds a layer in front
Basic DDoS mitigation	Always on, no configuration needed
CDN caching	Meaningful for the Portal's static assets; no benefit for API JSON traffic
WebSocket support	Works out of the box if live driver tracking needs it

Two things to decide before enabling it: DNS for the domains you proxy needs to move to Cloudflare's nameservers, away from Plesk. And MinIO's domain should stay unproxied — Cloudflare's terms restrict using the free/Pro tiers as a general file-hosting CDN for large non-HTML traffic, so route object storage direct rather than through the orange cloud.

Decisions needed

Three open calls before we start provisioning.

Application server: KVM 4 or KVM 8?

KVM 4 fixes today's measured problem. KVM 8 adds headroom for traffic growth and OSRM load spikes, for about ₹1,100/mo more.
Enable Cloudflare now, or after the server migration settles?

No dependency between the two — can be layered on at any point once DNS ownership is confirmed.
Timeline for the Postgres backup replica?

Not required for launch. Worth scheduling in the following sprint once the two-server split is stable.